home *** CD-ROM | disk | FTP | other *** search
/ ftp.cs.arizona.edu / ftp.cs.arizona.edu.tar / ftp.cs.arizona.edu / tsql / doc / tsql.mail / 000123_gadia@cs.iastate.edu _Thu May 13 19:10:52 1993.msg < prev    next >
Text File  |  1996-01-31  |  3KB  |  86 lines
  1. Message-Id: <199305140010.AA23347@optima.cs.arizona.edu>
  2. Received: from ren.cs.iastate.edu by optima.cs.arizona.edu (5.65c/15) via SMTP
  3.     id AA23347; Thu, 13 May 1993 17:10:52 MST
  4. Received: by ren.cs.iastate.edu
  5.     (16.8/16.2) id AA15497; Thu, 13 May 93 19:10:52 -0500
  6. From: Shashi K. Gadia <gadia@cs.iastate.edu>
  7. Subject: Benchmark database instance
  8. To: tsql@cs.arizona.edu
  9. Date: Thu, 13 May 93 19:10:52 CDT
  10. Cc: gadia@cs.iastate.edu
  11. Mailer: Elm [revision: 70.30]
  12.  
  13. I have four points to make about 
  14. the database instance. 
  15.  
  16. 1. Change in Ed (Edwards's) information.
  17. -----------------------------------------
  18. Ed's name changes at a time instant 
  19. at which he possesses all three skills.  
  20. In most models this will make the description 
  21. of his skills unnecessarily lengthy.  I 
  22. suggest two changes. 
  23.  
  24. A. Let the new name (Edward) start at 
  25.    1/1/89 instead of 1/1/88.  
  26.  
  27. B. Change end time of typing skill to 
  28.    12/31/87. 
  29.  
  30. With these changes, his name changes only 
  31. during the filing skill.  
  32.  
  33. 2. The Department <--> Manager dependency.
  34. ------------------------------------------
  35. The proposed instance fails to reflect 
  36. the complexity of the database scheme. 
  37. The situation in general can be much more
  38. interesting than the one exhibited while 
  39. still satisfying the two dependencies 
  40. (Department --> Manager, and Manager  
  41. --> Department).  The implication of these
  42. dependencies is that Department 
  43. can serve as a key, and if one wishes, 
  44. Manager can serve as the key.  Objects 
  45. viewed with respect to these different 
  46. keys are interwoven.  In addition, 
  47. even the number of tuples can be 
  48. different with respect to different 
  49. keys.  This is one of the interesting 
  50. peculiarities of temporal (and parametric) 
  51. databases which the community must 
  52. address.  
  53.  
  54. 3. Relation with a non-interval domain.
  55. --------------------------------------- 
  56. There is no relation whose domain 
  57. is a non-interval temporal element.  
  58.  
  59. 4. Representation of time points.
  60. ---------------------------------
  61. The time points are dates in the format 
  62. MM/DD/YY.  This is extremely distracting 
  63. and serves no purpose whatsoever.  
  64. Dates form a sequence 1/1/82, 1/2/82, ...
  65. etc.  So do integers 0, 1, 2, ... 
  66. The two structures are literally 
  67. isomorphic in our context.  There are many 
  68. reasons that dates are not desirable.  
  69.  
  70. A. An interval requires 19 characters.  
  71.    To draw an instance of emp relation I need
  72.    101 characters and spaces.  This is very
  73.    taxing in terms of document preparation.  
  74.  
  75. B. For a human it is much harder to compare 
  76.    dates than integers.  This becomes very taxing 
  77.    when we try to visualize what is retrieved 
  78.    by a query.  
  79.  
  80. I feel very strongly about these issues 
  81. which makes the benchmark document inaccessible 
  82. and less appealing.  
  83.  
  84. I will be willing to provide an instance 
  85. which takes these points into full 
  86. consideration.